The present disclosure relates to agent based technology for use with a Java Virtual Machine (JVM) and other analogous software environments.
In Java, a class represents the code to be executed. When a particular state is associated with a class, there exists an instance of that class. So different instances of the same class can have different state, but generally refer to the same code.
Source files (.java files) are compiled into (virtual) machine-readable class files which have a .class extension. Since Java is a platform-independent language, source code is compiled into an output file known as byte code, which is stored in the class file. If a source file has more than one class, each class is usually compiled into a separate class file. A JAR file (Java ARchive) is an archive file format typically used to aggregate many Java class files to distribute application software or libraries. JAR files are built on the ZIP file format and have the .jar file extension.
A JVM is the code execution component of the Java software platform. Class files can typically be loaded by any JVM. JVMs are available for many platforms, and the class file compiled for one platform should execute in a JVM of another platform. This makes Java platform-independent.
The Java Classloader is a part of the Java Runtime Environment that dynamically loads Java classes into the JVM. Usually, classes are only loaded on demand. When the JVM is started, three classloaders are used: the Bootstrap Classloader, the Extensions Classloader and the System Classloader. The Bootstrap Classloader loads the core Java libraries.
The Java Instrumentation API provides a means to allow Java programming language Agents to instrument or otherwise act on programs running in the JVM. One mechanism for instrumentation is modification of the byte code of the methods of the Java class files. An Agent is deployed as a JAR file (the agent.jar file). An attribute in the JAR file manifest specifies the Agent class which will be loaded to start the Agent. For implementations that support a command-line interface, an Agent is started by specifying an option on the command-line. Implementations may also support a mechanism to initiate agents after the JVM has started. For example, an implementation may provide a mechanism that allows a tool to attach to a running application, and initiate the loading of the tool's Agent into the running application.
On implementations with a command-line interface, an Agent is started by adding the following option to the command-line:                -javaagent:jarpath[=options]        
In the above command line option, jarpath is the path to the Agent's JAR file and options are the Agent options. This switch may be used multiple times on the same command-line, thus creating multiple Agents. More than one Agent may use the same jarpath. An Agent's JAR file must conform to the JAR file specification.
The manifest of the Agent's JAR file contains the attribute Premain-Class. The value of this attribute is the name of the Agent class. The Agent class implements a public static “premain” method similar in principle to the main application entry point. After the JVM has initialized, each “premain” method will be called in the order the Agents were specified, then the real application main method will be called. The Agent classes are loaded by the Bootstrap Classloader, which will lock the Agent's JAR file so that the code in the Agent's JAR file cannot normally be changed.